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Beschreibung 

Verfahren und Vorrichtung zur Behandlung von ortsbasierten 
Diensten 

5 

Fachgebiet der Erfindung 

Die Erfindung betrifft ein Verfahren fur ortsbasierte 
Dienste. Die Erfindung betrifft weiterhin eine Vorrichtung 
10 zur Durchfuhrung des erfindungsgemafien Verfahrens. 

* Heutige Dienste sind eng mit bestimmten Netzen verbunden und 

Teilnehmer benutzen Kennzeichnungen, welche diese Netze spe- 
zifizieren. Die meisten dieser Netze lassen ein Roaming in 

15 andere Access Netze zu und die Teilnehmer haben die Wahlfrei- 
heit, mehr als ein Netz zu nutzen, beispielsweise durch ein 
„Multimode* Terminal oder auch uber verschiedene Terminals. 
Auf der anderen Seite bieten verschiedene Anwendungsserver 
interessante Dienste an. Diese sollten unabhangig vom zugrun 

20 deliegenden Netz und den wechselnden Net z-Anbieter sein. Der 
Trend geht zu internationalen Dienst-Anbietern, die auch 
nicht von lokalen Umstanden beeintrachtigt sein wollen. Es 
ware daher vorteilhaft, einen Server anbieten zu konnen, der 
diese Unterschiede verbergen kann. 

■ Derzeit angebotene ortsbasierte Dienste erlauben es, einen 

Teilnehmer zu lokalisieren . Dienste, die mehr als einen Teil 
nehmer behandeln wollen, beispielsweise verschiedene „Identi 
taten* einer Person, oder unbekannte Identitaten in einem be 

30 stimmten Bereich unabhangig vom verwendeten Netz, benotigen 
eine aktuelle Datenbank mit einer Vielzahl von Inf ormationen 
liber die Netze und die von den Netzen abgedeckten Gebiete. 

Aktuelle Protokolle von 3GPP (3rd Generation Partnership 
35 Project, www.3gpp.org ) sind auf ortsbasierte Dienste ausge- 
richtet, die wenige Teilnehmer behandeln. Dienste, die alle 
angemeldeten Teilnehmer abdecken sollen, beispielsweise sta- 
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tistische Auswertungen mit feiner lokaler Genauigkeit Oder 
a : ch aul besti^te kieinere Gebiete begrenzte Dienste verur- 
sachen eine grone Mange an signalisierungsnachrichten und . 
triggern so viala ortsarmittlungvorganga . Wezterhzn 
triggern . t der p ri vatsphare nicht auf 

Implementierungen bezuglich Schutz aer rrx * 

eine hohere Abf ragedichte eingerichtet . 

Baispiala far hiervon betroffene Dienste sind: 

. Notfall-Information far ainan Bezirk: beisprelswerse 

SchlieBung eines Parks, Feuermeldung, Warnung vor Gefahren 
warbung fur aina Gebiet: Er6ffnung ainas nauan Gaschafts, 
Beginn einer Veranstaltung in wenigen Minuten... p 
Triggarn einas Dienstas, wenn dar Benutzar ein bestzmmtes 
Aral! batritt: z. B . Anbieten von spazieilar Information, 
waohsal zu einer besseren (Oder ganstigaren, Verbzndung, 

wie WLAN, bluetooth etc. 

Triggarn ainas Dianstes, wenn dar Banutzar arnan bestzmm- 
ten Litraum a. salban Ort bieibt: z. B. Anstehen an ezner 
■ Kassa Oder vor ainam Eingang, Batrachtan einar Anzezge 
(Poster), Warten an einer Hal testelle . . . 
. der Benutzer kann informiert werden, wenn ar sich ernes 
bestimmten Ort nahert, beispielsweise ainam Restaurant 

oder einem Hotel , . 

d er Benutzer wird informiert, wenn er sich exnem best«- 
ten anderen Benutzer oder einer Vorrichtung n^hert: 
Freund, Arbeitskollege, Mitspieler, Parkschexnautomat, - ■ • 
. der Benutzer wird informiert, wenn eine Person oder V r- 

roWp . ve rlasst: Diebstahlsicherung, Kind 
richtung em Gebiet veriasbL. 

verlasst Party etc. 
0 - ortsabh^ngige VergebUhrung : insbesondere muss der Te.lneh- 
m er informiert werden, dass sich die Vergebuhrung andert, 
wenn er ein Gebiet verlasst oder betrxtt. 
Statistische Auswertungen, wie Erxuittlung der Anzahl von 
Geraten in einem Gebiet, beispielsweise zur Erkennung ex- 
nes Verkehrsstaus, Reagieren auf den erhbhten Bedarf an 
offentlichen Verkehrsmitteln nach dem Ende eine exner Mas 
senveranstaltung wie Konzert, Sportveranstaltung etc. 
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Stand der Technik 

Ortsabhangige Dienste sind bislang noch in der Einf lihrungs- - 
5 phase und werden daher nicht . besonders haufig benutzt . . Viele 
der oben angegebenen Dienste sind noch nicht implementiert 
oder nur in einer schlechten Auflosung realisierbar , basie- 
rend auf Inf ormationen die derzeit im Netz verfugbar sind, 
wie die CelllD (Bezeichung einer Zelle eines zellularen Net- 

10 zes) oder LAC (Location Area Code - ein aus Zellen gebil- 

deter, grofterer Ortsbereich) . In der naheren Zukunft werden 
nur netzspezif ische Dienste angeboten werden, eine offene 
V Schnittstelle ist derzeit nicht vorgesehen. OMA/LIF (Open 
Mobile Alliance, Location Interoperability Forum, 

15 www. openmobilealliance . org ) und 3GPP beginnen erst damit, die 
Erweiterungen fur ortsabhangiges Triggern zu definieren. 

Weiterhin ist der Bedarf fur netzubergreif ende Dienste noch 
nicht in groiierem Umfang vorhanden, da es derzeit noch wenige 
20 Teilnehmer gibt, die verschiedene Zugangsnetze nebeneinander 
verwenden. Es zeichnet sich jedoch bereits ab, dass bei- 
spielsweise eine alternative Nutzung von GPRS (General Packet 
Radio Services) und WLAN (Wireless Local Area Network) immer 
popularer wird. 



' 25 



Bislang vorstellbare Losungen waren: 
- Zyklisches Pollen der Endgerate. Da es sich hier aber urn 
eine grofie Anzahl von Geraten handeln kann, wird ein hoher 
Datenf luss er zeugt 
30 - Einbeziehen aller Teilnehmer, wie Broadcast SMS. Keine 

spezielle Auswahl von Teilnehmern fur ein Service moglich 
(z.B. nur auslandischer Teilnehmer) 



35 



Aufgabe der Erfindung ist es, eine Ldsung fur ein verbes- 
sertes Anbieten von ortsabhangigen Diensten und die Losung 
der genannten Probleme anzugeben . 
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Darstellung der Erfindung 

Diese Aufgabe wird gelost durch ein Verfahren gemafi Anspruch 
1 und eine Vorrichtung gemali Anspruch 11. 

Die Erfindung betrifft ein Verfahren zur Behandlung eines 
ortsabhangigen Dienstes, fur einen abgegrenzten geographr- 
schen Bereich (im folgenden auch als Area bezeichnet) der be- 
dient wird von mindestens zwei Einrichtungen zur Bestimmung 
der geographischen Position von Mobilf unknutzern (GMLC) , fur 
eine Mehrzahl von Teilnehmern in diesem geographischen 
Bereich. 

Der ortsabhangige Dienst (LCS) sendet eine Anfrage zur Iden- 
tity von Teilnehmern in einem geographischen Bereich (Area) 
an ein zentrales Netzelement (LAS1) . Das zentrale Netzelement 
erfragt nun die aktuelle Information Uber die in dem 
abgegrenzten geographischen Bereich aktiven Teilnehmern von 
den mindestens zwei Einrichtungen zur Bestimmung der geogra- 
phischen Position von Mobilf unknutzern (GMLC) . Das zentrale 
Netzelement liefert dann das Ergebnis dem ortsabhangrgen 
Dienst (LCS) zuruck. 

in der erf indungsgemafien Losung ist das frei wahlbare Gebiet 
nicht auf einen Netzbetreiber beschrankt. Der externe Orts- 
dienst-Client, external LCS (Location Services) Client, muss 
die Anfrage nicht mehr an alle Netzbetreiber verteilen, die 
in dieser Area ihre Dienste anbieten, dies erledigt das zent 
rale Netzelement fur ihn. Solange es sich urn 3GPP Netze han- 
delt ist dies ein kleineres Problem, da diese nur in gerrnge 
Anzahl vorhandenund allgemein bekannt sind. Aber bei den 
WLAN Netzen ergibt sich eine andere Situation, da es sich 
hier urn ein schnell wandelndes Geschaft handelt. 

Ein zusatzlicher Netzknoten wird nun eingefuhrt, der alle 
Netzbetreiber und deren ortlichen Operations-Radius enthalt. 
Das zentrale Netzelement, das sich mit dem Zusammenspiel dei 
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Netzbetreiber beschaftigt, gibt Drittanbietern von Diensten 
die Moglichkeit, gunstig und schnell eigene, kleine Anwendun- 
gen anzubieten. Endbenutzer, Netzbetreiber und Anwendungsent- 
wickler profitieren von einem solchen Ansatz. 

5 

Die vom zentralen Netzelement durchgefuhrte Verteilung von 
Funktionalitaten auf viele verbundene Netzknoten, die von 
verschiedenen Betreibern kontrolliert werden, unterstUtzt 
Drittanbieter von Diensten, ihre Dienste auch in Areas anzu- 
10 bieten, die durch technologische, administrative oder 
juristische Grenzen erschwert werden. 

f Diese zentralen Netzelemente losen ebenso dynamische Probleme 

durch die Reduzierung von Netzlast und Einsatz von Caches. 
15 (Zwischenspeicher) . 

Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den 
Unteranspruchen angegeben . 

20 

Kurzbeschreibung der Zeichnungen 

Im folgenden wird die Erfindung anhand von Ausf uhrungsbei- 
spielen erlautert. Dabei zeigen 

.25 Figur 1 eine existierende 3GPP Netzarchitektur mit der erfin- 

dungsgemafien Erganzung 
Figur 2 eine Architektur mit dem Local Area Server LAS 
Figur 3 verschiedene geographische Bereiche, die durch einen 

LAS versorgt werden, 
30 Figur 4 von einem Local Area Server LAS abgedeckter 

geographischer Bereich, in Baumstruktur dargestellt, 
Figur 5 ein Beispiel fur verschiedene, unabhangige Anforde- 

rungen und 
Figur 6 ein Datenf lussdiagramm. 
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Beschreibung der bevorzugten Ausgestaltungsf ormen 

A. Architektur und Oberblick 

Figur 1 zeigt die aktuelle 3GPP Netz Architektur, wie sie in 
der Spezifikation 3GPP TS 23.002 (V5.9.0, 2002-12): Network 
Architecture,, in Kapitel 5.2.2 abgebildet ist. Dort ist auch 
eine weitergehende Beschreibung der Netzelemente und Schmtt- 
stellen (Lh, Le, Lc, Lg, lu, lur, lub, Uu etc.) zu finden. 

Im Heimatregister, Home Location Register HLR, sind dem Mo- 

^. ■ v^^^iirri i rh Teilnehmerinf ormationen 
bilfunkteilnehmer Exntrage bezuglicft lennei 

zugewiesen. 

Das Besuchsregister, Visitor Location Register VLR ist das 
lokale Register fur vermittlungsgebundene Dienste. Es wxrd 
von der Mobilvermittlungsstelle, Mobile Switching Center, 
MSG, benutzt, ura Inf ormationen uber „roamende* Teilnehmer 
also solche von eigenen und fremden Mobilf unkbetrerbern, dxe 
sich in dem Gebiet aufhalten, zu erhalten und deren Rufe zu 
behandeln. 

Im Gegensatz dazu wird der GPRS Netzknoten, Serving GPRS 
Support Node, SGSN, zur Speicherung von Teilnehmer information 
fur paketorientierte Dienste in eine, Mobilfunknetz benotxgt. 

Die Mobilvermittlungsstelle, Mobile-services Switching 
Centre, MSG, stellt auch die Schnittstelle zwischen dem 
Mobilfunknetz und dem Festnetz dar . Die Vermittlungsstelle 
fuhrt alle notwendigen Funktionen durch urn leitungsvermxt- 
telte Dienste von und zur Mobi Istation. abzuwickeln. 

Das Gateway Mobile Location Center, GMLC, ist der erste Netz 
knoten, auf den ein ortsabhangiger Dienst in einem Mobxlfunk 
netz Zugriff hat. Es fuhrt die Autorisation durch und fragt 
beim Heimatregister HLR die Routing Inf ormationen ab. 
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Im folgenden steht der GMLC auch fur andere Netzknoten, wie 
WLAN Zugrif f spunkte (auch Hotspots genannt) , Festnetz etc., 
die den Zugang fiir ortsabhangige Dienste bilden. 

5 Ein Node B ist eine logische Net zkomponente, die eine oder 
mehrere Zellen bedient. Ein Radio Network Controller RNC ist 
eine Netzkomponente im Mobilf unknetz, die ein oder mehrere 
Node B kontrolliert . 

10 Die Positionierungseinheit , Location Measurement Unit LMU, 
fuhrt Funkmessungen durch um Positionierungsmethoden zu un- 
» terstutzen. Es sind zwei Typen von LMU definiert: 




Type A: Zugriff liber die normale GSM Luf tschnittstelle 



(U m ) , es ist keine Drahtverbindung zu einem anderen Netz- 
15 element vorhanden. 

Type B: Zugriff uber das Basisstation - Controller Inter- 
face (Iub) . Das LMU kann ein Stand-Alone Netzelement mit 
einer Pseudo-Cell ID sein oder in einen Node B integriert 
sein. 

20 

Der Serving Radio Network Controller SRNC koordiniert die 
Ortsanfragen abhangig von der Prioritat und wahlt die geeig- 
nete Ortsbestimmungs-Methode aus . Er kann eine Schnittstelle 
zum Controlling Radio Network Controller CRNC aufweisen, die 
25 hauptsachlich Hilfsmittel zur Positionsbestimmung des Endge- 
' rates aufweist und entsprechende Messung von den Netzknoten 
Node B und LMU abfragt. 

Eine Beschreibung von Ortsbest immungsmethoden findet sich z. 
30 B. in dem Artikel "Convex Position Estimation in Wireless 

Sensor Networks' 7 von Lance Doherty, Kristofer S. J. Pister, 
Laufent El Ghaoui, Infocom 2001, Anchorage, AK, April 2001, 
( http : //www-bsac . eecs .berkeley . edu/-ldoherty/inf ocom.pdf ) 



35 



Die GSM Service Control Function, gsmSCF, ist eine funktio- 
nelle Einheit, die die CAMEL Dienstelogik zur Implementierung 
von betreiberspezif ischen Diensten enthalt. 
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Das cell Broadcast Center, CEC, 1st verantwortlzch fur das 
Management von CBS (cell broadcast service, Machrrchten und 
d er Obermittlung von CBS Nachrichten an das RNS (Radro Net- 
work System) . 

FUr den vorliegenden Fall 1st nur der rechte Tell de, : Flgu. : 1 
relevant. Bin externer LCS Ortsdlenst-Clrent fragt Or 
information vom Netz uber eine L. Schnzttstelle ab (3GPP be 
"ttt das Mobile Location Protoxoll MLP .LIE/CMA, TS 101 
specification: MLP Mobile Location Protocol). 

1 »r eine Oder mehrere ID' . -It def inierter Genauzgkezt 
abgefragt warden. Dieses Protokoll kann Jedoch nur mzt eznem 
Ztl umgehen, das durch den externen LCS r^^ 1 ""' 
lit Hilfe der Teilnehmer Id ausgewahlt wurde. In Zukunft soil 
dieses Protoxoll auch fur Internationale Telle anwendbar 



sein . 



3 
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Ein neues Netzelement, Location Area Server LAS, und ern 

es Protoxoll, Location Area Protocol LAP, zur Handhabung 
von Areas, warden eingefuhrt. Der Location Area Server befrn- 

^ i H^m External LCS Ortsdienst- 

det sich zwischen oder neben dem External 

Client und den verschiedenen Netzen. 

Fi gur 2 zeigt das neue Netzelement, Location Area Server LAS- 
una seine Position i- Netz. Die verschienen Mobz funk- oder 
WLAN-Operatoren xbnnen kooperieren und das Netzelement LAS 
™den urn ibre eigenen Netzelemente zu entlasten und ver 
schiedene Technologien zu integrieren. Auf der anderen Serte 
1 d as LAS konkurrierende Netze verbinden und es externen 
^wendungen erlauben, Zugriff auf diese Netze zu er angen. 
Der LAS hat eine Datenbanx, die die tatsachlzche Netzab- 
deckung speichert . Jeder LAS 1st fur ein gewisses Gebiet zu- 
standig. Das Gebiet, das durcb einen LAS bedient wxrd kann 
ein Land, ein Kontinent oder aucb eine kleinere Exnhert dar- 

• n.w „p ite rhin ein InterLAS Protokoll zwl- 
stellen. Es existiert weiternrn e 

schen zwei LAS und auch ein Mechanismus zur Auswahl des 
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richtigen LAS. Die Anfragen, die von einem externen LCS Orts- 
dienst-Client empfangen werden, sind nicht auf das Gebiet be- 
grenzt, das von einem einzelnen LAS abgedeckt wird. Die 
Kommunikation mit dem External LCS Ortsdienst-Client erfolgt 
uber das Location Area Protocol, LAP. Dieses kann ebenfalls 
fur die Kommunikation mit den Netzknoten GLMC oder WLAN 
hotspot verwendet werden, existierende Standardprotokolle 
sind ebenfalls moglich, es mussen allerdings EinbuJJen in der 
Funktionalitat hingenommen werden. 

0. Schritt: 

Vorausset zung ist die Konf igur ation des LAS. Jeder LAS ent- 
halt eine Tabelle, die Adressen von Netzknoten und vom LAS 
bediente Orts-Bereiche enthalt. Diese Eintrage konnen sta- 
tisch, beispielsweise von einem Operator eingetragen sein, 
oder dynamisch von einem Protokoll ahnlich zu dem in Schritt 
1 beschriebenen, erzeugt werden. 

1. Schritt: 

Die Ortsbereichs-Daten im LAS mussen dynamisch auf den neues- 
ten Stand gebracht werden. Sobald ein neuer Netzknoten seinen 
Dienst anbietet oder die Topologie sich andert, informiert 
dieser Netzknoten den nachsten LAS uber den neuen bedienten 
Bereich (Area) . Dafur sendet er eine Nachricht 
LAP : UPDATE_LOCAT I ON_AREA 

an den LAS mit hinzugef iigten oder entfernten Gebieten, spezi- 
fiziert z. B. durch eine Liste von Koordinaten, wie 
beispielsweise im MLP Protokoll beschrieben. Dort wird der 
Netzknoten Identif ikator , die Adresse des Netzknoten und die 
bediente Area gespeichert. Wenn der ganze Bereich oder ein 
Teil davon auch noch von einem oder mehreren zusatzlichen LAS 
bedient wird, so wird die Nachricht auch an diese LAS weiter- 
geleitet. Die Adressen dieser zusatzlichen LAS werden, zu- 
sammen mit dem Netzknoten Identif ikator , fur weitere Aktionen 
gespeichert. 
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Sobald der LAS bei der Sendung von Nachrichten an 
Netzeinheiten eine Zeituberschreitung erhalt, markiert er das 
Netz als „nicht erreichbar* um seine Datenbank aktuell zu 
halten. Der LAS leitet diese Information an alle von dem Aus- 
fall dieser Netzeinheit betroffenen zusatzlichen LAS welter.. 

Um unnotige Nachrichten zu vermeiden, sollte jeder Netzknoten 
den LAS daruber informieren, ob er verfugbar ist.Zu diesem 
Zweck wird eine Nachricht 
LAP : OPERAT I ONAL_AGAIN 

nach einem Ausfall an den LAS gesendet. 

i .. . _,,,_>, Ha<; Problem von redundanten *f 
Dieser Mechanismus lost auch das rrooxem • 

Netzelementen. Falls das Netz Nr. 1 zwei GMLC zur Bedienung 
der selben Area verwendet, kdnnen beide die Area dem LAS be- 
kannt machen. Der LAS wird den Betrieb soweit fortfuhren, xn- 
dem er alle Anfragen dupliziert, solange bis einer der GMLC 
nicht mehr antwortet. Sobald der GMLC wieder betriebsberert 
ist, meldet er sich bei dem LAS und erhalt wieder Kopien der 
Nachrichten . 

2. Schritt: 

Wenn der LAS die Nachricht 
LAP : AREA_REQUE S T 

von einem externen LCS Ortsdienst-Client erhalt, die erne ., 
Definition einer Area enthalt, tiberpruft der LAS die Area und 
seine Verantwortlichkeit . Fur die Telle von der Area, die von 
anderen LAS verwaltet werden, leitet er die Anfrage an diese 
LAS weiter. Fur den selbst verwalteter Teil der Area beginnt 
, • er, alle Netzknoten die beteiligt sind und deren zustandrge 
Areas zu bestimmen. 

Figur 3 zeigt ein Beispiel fur die Area, die durch einen LAS 
betreut wird. Drei Netzknoten, Network Node [1, 2, 3], haben 
ihre betreuten Areas (vereinfacht dargestellt als Rechtecke) 
bekannt gegeben. Die gewunschte Area (eine Ellipse) wird nun 
gescannt und in drei Areas, AreaU, 2, 3], zerlegt. Neue Sub- 



5 
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areas werden gebildet: Subarea 1 bestehend aus Areal.und 
Area2 wird verwendet fur Netzknoten Network Node 1 und Sub- 
area 2, bestehend aus Area2 und Area3 wird verwendet fur Net- 
work Node 2. Network Node 3 ist von dieser Anfrage nicht be- 
5 troffen. 

3. Schritt: 

Die empfangene Anfrage wird nun an alle ausgewahlten Netzkno- 
ten weitergeleitet, enthalten sind nur die gewiinschten sub- 

10 areas. Die erhaltenen Antworten werden zum auslosenden 

external LCS Ortsdienst-Client geleitet, entweder von alien 
Netzknoten gesammelt oder einzeln, sobald sie eintreffen, ab- 

t hangig von der Festlegung in der urspriinglichen Anfrage. So- 
fern ein Netzknoten nicht antwortet, wird er auf die Liste 

15 der nicht erreichbaren Netzknoten gesetzt (siehe 1. Schritt). 

B. Identif ikation 

20 Alle bekannten Protokolle, die Ortsinf ormationen abfragen, 
wie das MLP. (LIF/OMA) , benotigen die Identitat des Teilneh- 
mers, fur den die Ortsinf ormat ion abgefragt wird. Diese Iden- 
titatsinformationen liegen in verschiedenen Formaten vor, ab- 
hangig von den verwendeten Technologien . Beispielsweise sieht 

25 eine Internet-Adresse (IP V.4 oder IP V.6) anders aus als 
eine E.164 Nummer. Externe LCS Ortsdiens t-Clients sollen 
nicht mit diesen unterschiedlichen Formaten konfrontiert wer- 
den, vorteilhafterweise libernimmt der LAS die Auflosung. 

30 Fur angefragte Areas kennt der external LCS Ortsdienst-Client 
normalerweise diese Identitaten der Teilnehmer nicht. Natur- 
lich ware es das Beste, wenn das Netz dieses Problem losen 
und ein Protokoll anbieten wiirde, welches auch bei unbekann- 
ter Identitat eine Ortabfrage erlaubt. Dieses wiirde aller- 

35 dings auch eine Reihe von Bedenken hinsichtlich Schutz der 

Privatsphare aufbringen, wenn alien externen LCS Ortsdienst- 
Clients erlaubt wiirde, die Teilnehmer eines Netzes aufzuspli- 
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ren Aufierdem wurde es zu grolien Nachrichten rait langen 

u ieT eiln^ern fUhren. Auch wenn keine RUcKgabe von 

Identitlten in der Anfrage verlangt wUrde, so .Usste die 

« eine Liste von alien Teilnehraern .it i^ner 

^entifizierung und Auf enthaltsort enthalten und auBerdem 

Identirizieiu y Anfrage nicht er- 

a :„ Tiste von den Teilnehmern, fur die aie « y 

folgr e ch war, entweder well der gesucbte Teller abwesend 

1st Oder dessen Batenscnutzregeln eine »fra,e von drese, 

external LCS ortsdienst-Client nicht gestatten. 

Ein Netzknoten betrieben in einer vertranenswUrdigen <M- 

gebung entweder durcn gesetzlicbe Berecbtigung Oder dutch 

fen Tetzbetreiber selbst, xOnnte dieses Problem losen. % 

r. r- 0 r,v^nk die die Zuordnung zwischen 
^ tsc onrhalt erne DatenoanK, " ie v - tJ - 
TLZ^TZ den verantwortl.chen Netzknoten beinhaltet. 



Schritt 1: ah ^anden die Datenbank im 

Die Netzknoten aktualisieren in Abstanden a 

.^-x. ^-i^ Hprzeit von ihnen bedient 
20 LAS rait alien Identitaten, die derzeit 

werden, mithilfe von 
LAP : UPDATE_I DENT I T IES . 
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renn'der^ eine *n f ragenachricht vo» external LCS Orts- . ( 
dienst-Client erhalt 

LAP: AREA REQUESTS seiner ■ 

~~ 7Nr,-fr- afT P an iede Identitat, die m seiner 

verteilt er diese Anfrage an jeu 

Datenbank fttr diesen Netzknoten gespeichert ist. 
Schritt 3: 

Alle erfolgreichen Antworten 
TAP- AREA REQUEST RESP 

LAP. ARKf\_ u _ Teilnehmern werden zum ex- 

I 0 " 1 - nt weitergeleitet, entweder gesa,- 

Damit wird der external Ortsdienst-Clzent entlastet, 



200303277 



13 

empfangt keine nicht-relevanten Informationen, zum Beispiel 
uber Teilnehmer,. die ■ sich nicht in der angef orderten Area be- 
finden, aber die in dem Netz existieren. 

Wenn das benut zte Protokoll zwischen LAS und GMLC (z.B.MLP) 
es nicht erlaubt, eine Area in ausreichender Genauigkeit zu 
spezif izieren, so muss die Position jedes Teilnehmers einzeln 
abgefragt werden und nur solche, die sich in der gewlinschten 
Area befinden, werden zuruckgemeldet . 

Dieses Vorgehen ist von Vorteil da die Anzahl von Anfragen an 
die Area reduziert wird, wenn nur aktive Identitaten benutzt 
werden. Der LCS client muss nichts liber die interne Struktur 
der Identitaten wissen, und die Grofie und Anzahl der Nach- 
richten wird reduziert. Auch der Datenschutz von Teilnehmern, 
die nicht abgefragt werden, ist so gewahrleistet , da keine 
Daten vom LAS zum LCS client gesendet werden. 

Das Netz muss hier aber alle Teilnehmer an das LAS melden. 
Dabei werden interne Daten weitergeleitet , sowie die Benut- 
zungsf requenz . Urn dieses Datenschut zproblem zu losen, konnen 
LAS kaskadiert werden. Einer befindet sich im Netz des 
Betreibers und bekommt die Nachricht 
LAP : UPDATE_IDENTITIES 

und ein weiterer LAS verbindet verschiedene Netze, aber. er- 
halt keine Informationen uber Identitaten. 

Vorteilhafte Ausgestaltungen sind moglich: 
Variante A 

Fur Netzknoten, die eine grofie Area bedienen, kann es vor- 
teilhaft sein, in die Nachricht 
LAP : UPDATE_I DENT ITIES 

Ortsinf ormationen einzufligen, beispielsweise die 3GPP loca- 
tion Area. Die Anzahl von LAP: UPDATE_IDENTITIES -Nachrichten 
wird zunehmen, aber der LAS kann dann nur Identitaten in den 
angeforderten Areas verwenden und so die Anzahl der Nach- 
richten an das jeweilige Netz reduzieren. 
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10 
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Modif izierter Schritt 1: 

Der LAS hat interne Regeln fur die Konstruktion von 
IdentiWten, abh.ngig von jedem benutzten Netz, entweder vor- 
definiert oder mit der Nachricht 
LAP: UPDATE LOCAT I ON_AREA 

vom GMLC erhalten. Es erstellt dann jeden mbglichen Identifi" 
zierer oder benutzt wildcard-Mechanismen, die von dxesem Netz 
erlaubt werden, um eine Nachricht zu ubermitteln (zum Bex- 
spiel „MLP: Triggered Location Reporting Request*), dxe exne 

-,•■+- f a n- rlas Obiekt sich ins Netz exnbucht. 
Rtickmeldung auslost, falls das odd ex l 

Wenn es einen solchen Report bekommt und dieser Report 
anzeigt, dass der Teilnehmer verfUgbar ist, dann kann es 
einen periodischen Trigger setzen, um. die ortsabhangxgen 
Informationen in einer etwas besseren Genauigkeit zu erhal- 
ten, beispielsweise in Location Areas. Mit dxesem standard 
Protokollmechanismus kann der LAS seine Datenbank bestehend 
aus identitaten, Netzknoten und bekannten Ortsinf ormatxonen 
fullen, ohne dass eine Anderung im Netz notwendig ware. 

1^^%!- Vielzahl von Applikationen, bei denen der exter- 
nal LCS Ortsdienst-Client die Identity des lokalxsxerten Ob- 
jek ts nicht kennen muss. Es kann ausreichend sein, exne In- 
i formation an alle lokalisierten Objekte zu schicken In dxe- ^ 
sem Fall reicht eine kleinere Modifikation des Protokolls 
aus, um auch dieses Problem zu losen: 

Modif izierter Schritt 3: 
0 Bei Erhalt der Antworten 
LAP: AREA REQUEST_RESP 

in den angef orderten Areas saxnmelt der LAS alle Identxtaten 
zusammen mit F.higkeiten und Eigenschaf ten von benutzten End- 
ger.ten und gegebenenf alls Identif ikatoren dafUr (zum Bex- 
,5 spiel SMS, WAP, SIP, E-Mailadressen, Voice-Mail, Sprache ) . 
Diese Moglichkeiten und Voreinstellungen kdnnen auch durch 
den LAS direkt von einem Server, der diese Daten halt, ab- 
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gerufen werden. Ein temporarer Identif ikator fur diese Liste 
von Identitaten wird dann an den external LCS Ortsdienst- 
Client zuriickgeschickt, zusammen mit statistischen 
Informationen, beispielsweise wie viele Teilnehmer gefunden 
wurden, wie viele davon SMS benutzen konnen usw. 

Schritt 4 : 

Der externe LCS Ortsdienst-Client kann dann bestimmte Teile 
der Informationen, beispielsweise eine Web-Adresse, eine Te- 
le fonnummer, eine Kur znachricht oder Ahnliches an diese tern- 
porare Liste adressieren, indem er die Nachricht 
LAP:. SUBMIT_INFO 

benutzt. Der LAS kann diese Information entsprechend der von 
ihm gespeicherten Benut zerprof ile an alle Teilnehmer dieser 
temporare Liste weitersenden . 

Viele der beschriebenen Algorithmen konnen auch vom external 
LCS Ortsdienst-Client selbst durchgefiihrt werden. Da es aber 
eine Menge unabhangiger external LCS Ortsdienst-Clients im 
Netz gibt, wurde es die Netzbelastung durch eine Vielzahl von 
Nachrichten sehr erhohen. Es ist daher vorteilhaft, einen 
zentralen Netzknoten einzufiihren, der von einem zuver- 
lassigen, vertrauenswiirdigen Betreiber gefuhrt wird. So 
konnen auch die Netze verschiedener Net zbetreiber und ver- 
schiedener Technologien einfach kombiniert werden. 

C. Dynamische Optimierung mit AREA_IDENTITY 

Die von Applikationen benutzten Areas sind normalerweise sym- 
bolisch definiert, beispielsweise ein Land, eine Stadt, ein 
Gebaude oder eine Einkauf spassage . Diese Areas konnen natiir- 
lich durch ein Polygon reprasentiert werden, das aus einer 
Menge von Punkten und Kanten besteht, siehe zum Beispiel die 
Spezif ikation LIF TS 101. Es ist kein Problem zu berechnen, 
ob sich die Position eines gesuchten Objekts innerhalb eines 
gesuchten Polygons befindet. Allerdings ist dafur ein er- 
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hohter Rechenaufwand notig, vor allem wenn festgestellt 
werden soli, ob das Objekt eine Grenze uberschreitet . Hierfur 
1st eine haufige Durchfuhrung dieser Berechnungen fur eine 
hohe Anzahl von moglichen Objekten und fur alle uberpruften 
5 Areas notwendig, was die Leistungsgrenzen heutiger 

Netzelemente ubersteigt. Daher ist es wunschenswert , eine 
solche Area nicht in Polygonen auszurechnen, sondern in 
anderen netzspezif ischen Bereichen zu definieren. Dieses kann 
bei WLAN ein Subnetz sein Oder fur 3GPP Ortsareas (LAC) und 
10 Zellen (CI) . 

Figur 4 zeigt die geografische Struktur, die von einem LAS 
betreut wird. Dessen Zustandigkeitsbereich besteht aus einen W 
WLAN und zwei GMLCs . Die GMLC-Areas wiederum werden abgedeckt 
15 von einem oder mehreren MSC-SGSN. Diese wiederum sind 

aufgeteilt in Locationareas und die Locationsareas bestehen 
aus Funkzellen. Zellulare Netze sind ublicherweise in einer 
solchen hierarchischen Struktur aufgebaut. Beispielsweise ist 
. 3GPP so definiert, dass ein HLR die MSC-Area eines Teilneh- 
20 mers kennt, in der dieser sich gerade aufhait. Die MSG weiii 
immer die letzte Looationarea eines Teilnehmers. Nur in 
manchen Fallen, beispielsweise wenn der Teilnehmer gerade 
telefoniert, ist die tatsachliohe Zelle bekannt. Die prazise 
Aufenthaltsposition kann ansonsten nur duroh eine explizite 
25 Anfrage an das Radionetz oder an die Teilnehmerstation ^ 
herausgefunden werden. 

Ein Algorithmus zur Vermeidung wiederholten Pollings der 
Position konnte so aussehen: In der ersten Naherung wird eine 

30 Menge von die gewunschte Area umschlieBenden Location Areas 
LA getriggert. Ist das Zielobjekt in einer dieser Location 
Areas, so kann eine Positionierungsmethode mit feinerer 
Genauigkeit angewendet werden, beispielsweise basierend auf 
den Funkzellen. Eine feinere Bestimmung kann unndtig sein, 

35 wenn die geforderte Genauigkeit nicht sehr hoch ist oder die 
Funkzellen klein sind. 
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Zur Verwendung des erf indungsgemailen Mechanismus muss der 
gewunschte Bereich, der durch Polygone oder einer 
Zusammensetzung von Ellipsen und Rechtecken gegeben ist, in 
Location Areas umgewandelt werden. Der dazu notwendige 
Verarbeitungsvorgang kann je nach GroJie des Bereiches recht 
aufwandig sein und sollte vermieden werden. Auch Verande- 
rungen der Netztopologie soil ten fur den external LCS 
Ortsdienst-Client unbemerkt bleiben und transparent sein. 

Im folgenden wird also ein Vorgang angegeben, wie ein 
gewiinschter Bereich einnialig vom LAS umgewandelt wird und ein 
Identif ikator fur diesen Bereich fur weitere Benlitzung an den 
externen LCS Ortsdienst zuruckgelief ert wird. Dafiir ist 
allerdings die Offenlegung der Lage der netzinternen Location 
Areas er f orderlich . Dies kann Probleme darstellen, da Netz- 
betreiber moglicherweise die interne Struktur ihres Netzes 
nicht offen legen wollen. 

Das weitere Vorgehen des LAS hangt von der Benutzerstruktur 
ab, ob der LAS einem Net zbetreiber gehort oder net zbetreiber- 
ubergreifend agiert. Sofern der LAS mehreren Net zbetreibern 
gehort, kann vorteilhaf terweise ein kaskadierter Aufbau ge- 
wahlt werden, wie oben beschrieben. Dann schickt der externe 
Client seine Anfrage an einem mehreren Net zbetreibern zuge- 
horigen LAS, der sich gemafi Algorithmus A verhalt. Danach 
sendet dieser LAS die Anfrage an die net zbetreiberinternen 
LAS gemali Algorithmus B. 

Algorithmus A: Der LAS kennt die interne Struktur des Netzes 
nicht. 

Schritt 1: 

Der externe Client sendet eine Nachricht 
LAP: REQUEST_AREA_IDENTIFIER 

zu dem LAS. Diese Nachricht enthalt die vollstandige Defini- 
tion einer Area. 
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Schritt 2: 

Der LAS fUhrt eine Verarbeitung dieser Area durch «. be 
reits in Teil A, Schritt 2 beschrieben. Dabei wird die Nach- 
richt 

LAP- REQUEST AREA IDENTIFIER 

„e„n notwendig zu'anderen LAS weitergeleitet . Dae Ergebnis 
Tird in der Datenbank gespeichert. Es besteht aus einer Lxste 
von betroffenen Einheiten und die Subareas for diese 

•,- srhaltenen Identif ikatoren von 

Einheiten, zusammen mit den ernaltenen . 

anderen LAS. Bei Anderungen i» Netz, wie in Teil A, Schritt 1 
^schrieben, wird eine Aktualisierung der Daten durchge uhrt. 
Da diese Aktualisierung nur sporadisch notwendig 1st, 1st , 
jedenfalls ein Perf ormancegewinn zu erwarten. 

Der r LAS speichert die Definition der Area zusa^en mit dem 
erhaltenen Resultat, erzeugt einen eindeutigen Namen 
AREA IDENTITY und sendet diesen mit der Nachricht 
LAP~REQUEST AREA IDENTIFIER_RESPONSE zurttck. 
Dieser Identif ikaror 1st i» weiteren Verlauf fur externe 
Clients und auch von anderen Applikationen die davon Kenntms 
erhalten haben , benutzbar. Weitere Mechanise zur Pflege 
dieser Identif ikatoren, beispielsweise das Verwerfen des 
Eintrags, wenn er nicht innerhalb einer Anzahl von Tagen 
benutzt wird Oder die checksu^enbildung, sind notwendig und 
dem Eachmann bekannt. Zusatzliche Infor m ationen konnen eben- 
fllls enthalten sein, beispielsweise ein lesbarer Bezeichner 
de oie Beschaffenheit dieser Area beschreibt, wie Ernkaufs 
zentrum XV Oder „Stadt M - . 1st die angeforderte Area be- 
reits in der Datenbank des LAS enthalten, so wird der 
gespeicherte Identif ikator AREA_IDENTITY zuruckgelief ert 
vorteilhafterweise warden durch den LAS Operator berert be- 
stimmte Identifikatoren vordef iniert, beispielsweise Stadte 
oder Lander. 
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Schritt 4: 

Die ermittelte Oder definierte AREA__I DENT I T Y kann dann fur 
Nachrichten wie LAP: ARE A_RE QUE S T benutzt werden, wie welter 
oben beschrieben. Die Benutzung dieser Identif ikatoren kann 
gefordert werden, beispielsweise durch die Verrechnung 
geringerer Gebiihren oder durch die erhohte Prioritat bei der 
Beantwortung der Nachrichten. 



10 Algorithmus B: LAS kennt die interne Struktur des Netzes. 

Schritt 0: 
Die Nachricht 
LAP : UPDATE_LOCAT 1 0N_AREA 
15 wie weiter oben beschrieben, enthalt auiierdem die interne 
Struktur einer behandelten Area, eine Liste. von Location 
Areas und optional auch eine Liste von Funkzellen. 

Schritt 1: 

20 siehe oben Algorithmus A, Schritt 1 
Schritt 2: 

siehe oben Schritt 2 

Zusatzlich wird in der Datenbank eine Liste von Location 
J25 Areas und optional auch von Funkzellen fur jede AREA__I DENT I T Y 
gespeichert. 

Schritte 3 und 4: 

siehe oben Schritt 3 und Schritt 4 



30 



Diese Funktionalitaten konnen naturlich auch in der MSC-SGSN 
physikalisch integriert sein. 



35 



D. Dynamische Optimierung bei vielen Clients 
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Das Netz bekOMnt unterschiedliche unabhangige Anfragen fur 
ve schiedene Areas von verschiedenen unabhan g igen Anwendun- 
„en Applications) , die sich auf vielen externa! clrents be 
finden »enn das Netz diese Anfragen unabhangrg vonernander 
frnden. wenn ube rf lUssigen Verkehr. Der be- 

behandelt, generrert es vxel uberf , au£uand igen 

«f-hriebene Algorithmus soil dazu runren, 

schneoene g bestimmten Bedingungen aus- 

Positionierungsmethoden nur unter obiekt 
aefuhrt werden. Dabei wird zuerst f estgestellt, ob das Ob.ekt 
si n n Location Areas befindet, danach in Zellen und nur 

, ::: n da s si c h m ^ «.u. 

die eigentliche Positionierung ausgefuhrt. 

^rdHstgestellt, dass -aehrere Anfragen fur die gleiche Area 
9 angefordert werden .dies ^.^££f ~££ 1Ilsl 

„erden, dass bei ^"f^^ so kann die Anfrage 
-in dPn Anforderungen festgesteii^ wxj. 

"arch Z LAS selber behandelt werden. Dies geschreht entwe- 
der duroh Verwendung eines bereits rUckgemeldeten ( rm Cache, 

angef orders identische Anfragen von unab- 

Die Wahrscheinlichkeit fur zwei „ nnV „rrPnten 

4- ^.^v,r- horh. wenn viele Konkurrenten 
hanaiqen Anwendungen ist sehr hocn, wenu 

nangxgen ^ relativ groB ist, 

dieselben Dienste anbieten oder die Area re 

25 beispielsweise eine Stadt. 

2. Schritt: absolut identische Areas behan- 

30 Loca^on Areas oder Zellen fUhren. Das folgende Beispiel aus 
soil diese Idee verdeutlichen . Es wird ein Bereich 
aezeigt der aus zwei Location Areas, Location Area 1 und 
L ion Area 2 besteht. Diese Location Areas sind 
wiederum in Funkzellen (Cell 1.1, Cell 1.2, Cell 1.3, Cell 

35 2 1 usw ) aufgeteilt. Es existieren verschiedene Anwendungen 

' L rfrei Tarqet Areas stellen, also Zielgebiete, 

Hi^ TVnfraaen an arei larytju r^^. 

die Anirage Toca tion Areas und den Funkzellen 

die sich teilweise mit den Location «. 
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iiberdecken. In diesem Fall besteht nur ein kleiner 
uberlappender Bereich zwischen Target Area 1 und Target Area 
2. Target Area 1 uberdeckt dabei Location Area 1 und Location 
Area 2, Target Area 2 uberdeckt lediglich einen Teil von Lo- 
cation Area 2 und Target Area 3 ihrerseits nur Location Area 
1. Wenn eine Anfrage fur Target Area 1 eingeht, so kann die- 
ses Ergebnis spater ohne weitere Anfrage ebenfalls fur. die 
Target Area 2 beziehungsweise Target Area 3 verwendet werden, 
ohne noch einmal Inf ormationen von diesem MSC anzufordern. 
Fur die Target Area 1 mussen die Zellen Cell 2.1, Cell 2.2 
und Cell 2.4 angefragt werden. Diese Ergebnisse konnen spater 
fur die Target Area 2 wiederverwendet werden. 

Ein Algorithmus konnte wie folgt aussehen: 
Schritt 1 : 

Nach Erhalt eines Befehls 
LAP: AREA_REQUEST 

wird die angeforderte Area mit denjenigen verglichen, die 
kurz vorher beendet wurden, beziehungsweise deren Anfrage 
noch nicht fertig bearbeitet ist. Finden sich beim Vergleich 
Obereinstimmungen, so wird der gerade empfangene Request aus 
den bereits gespeicherten Antworten beantwortet oder solange 
verzogert, bis das Ergebnis verfugbar ist. Dabei ist zu 
beachten, dass unterschiedliche Parameter in der Anfrage 
vorhanden sein konnen, wie ^Quality of Service* -Parameter und 
Genauigkeit der Anfrage. 

Schritt 2: 

Nach Erhalt einer Liste von ausgewahlten Netzknoten wie in 
Teil A, Schritt 3 bereits beschrieben, oder der Liste von 
Location areas beziehungsweise Zellen, wie in Teil C, Algo- 
rithmus B, beschrieben, kann der LAS die Anfrage in eine 
Menge von einzelnen Operationen fur Subareas herunterbrechen. 
Fur jede Subarea wird die Anfrage behandelt wie zuvor in 
Schritt 1 beschrieben. Subareas fur die kein Resultat vor- 
liegt, werden gesammelt und die Anfragen dann an die GMLCs 
wei tergeleitet , wie bereits oben beschrieben: 
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Die eingehenden Resultate der neuen Anfragen werden im Cache 
gespeichert. zusaMnen mit einem Zeitstempel . Sobald .11. er- 
f orderlichen Informationen gesammelt sind, dxe fur die Ant- 
wort der ursprUnglichen Anfrage notwendig sind, wird zusammen 
mit den Resultaten aus dem Cache eine Antwort erzeugt. 
Optional konnen auch Teilergebnisse sofort an den «»t.™i 
client gesendet werden. Dieses verbessert zumindest fur einen 
Teil die Antwortzeiten und verteilt die Last liber die Zeit. 

Der zweite Schritt kann durch die beschriebene Architektur ^ 
und Datenbanken in LAS noch welter verbessert werden: 
Znn die Abfrage AREA REQUEST es erlaubt, dass auch Antworten 
mit einer grOKeren Dngenauigkeit zurUckgesendet werde, . Oder 
auch mit Ortinformationen, deren Zeitstempel welter zuruck 
liegt. kann LAS die Ergebnisse fruherer Anfragen zur Beant- 
wortung heranziehen. Dieses senkt die Anzahl der Anfragen, 
die an den GMLC weitergestellt werden mUssen. 

Auch die Kenntnis der internen Struktur von verschiedenen 
Netzbetreibern kann die Netzlast senken. 

Beispiel 1= Ein roamender Teilnehmer auGerhalb seines Heimat- 
net es kann sich alternativ in zwei Besuchsnetzen VPLMN1 und 
VPLMN2 einhuchen. Wenn der LAS die Position des Teilnehmers £ # 
in VPLMN1 genau kennt und kurz danach eine Anfrage fur VPLMN2 
erfolgt, der Teilnehmer inzwischen zu VPLMN2 gewechselt ist 
M * ' . . hskannt ist, kann auch aus der 

und nur diese Tatsache dem LAS bekannt ist, 

exakten position aus VPLMN1, der zeitdif f erenz und der 
durchschnittlichen Geschwindigkeit des Teilnehmers die gegen- 
wartige Position in der erf order! ichen Qualitat ausgerechnet 
werden, ohne dass eine neue, exaktere Ortsanfrage an das 
zweite Besuchernetz VPLMN2 durchgefuhrt werden muss. 

Beispiel 2: Hierzu kommen wir noch mal Figur 3 zuruck. Sofern 
bekannt ist, dass der Auf enthaltsort sich vor einiger Zeit in 
Networknode 1 befunden hat und eine durchschmttliche Ge- 
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schwindigkeit es dem Teilnehmer nicht erlaubt, sich bereits 
im Networknode 3-Bereich aufzuhalten, kann eine Anfrage an 
diesen vermieden werden. Durch Einsatz von Algorithmen die 
einige zurlickliegende Positionen des Teilnehmers beriick- 
sichtigen, kann auch die Genauigkeit ohne Abfrage der Netze 
gesteigert werden, Einige Algorithmen sind in dem bereits 
oben zitierten Dokument von Lance Doherty et. al . beschrie- 
ben . 

In Figur 6 findet sich eine Zusammenf assung der Algorithmen. 
Das Auf rufdiagramm istnur beispielhaft fur einige Aspekte 
der Erfindung, es ist auch nicht vollstandig, da einige not- 
wendige Antwortnachrichten weggelassen wurden. Dargestellt 
ist ein Ortsinf ormat ionsserver LAS, zwei Anwendungsprogramme 
external client 1 und 2, mit denen der LAS uber das Protokoll 
LAP kommuniziert, zwei Netze mit den Net zelementen GMLC1 und 
GMLC2, mit denen der Ortsinf ormationsserver uber das Proto- 
koll LAP -ML P kommuniziert, sowie ein zweiter Ortsinf ormati- 
onsserver LAS 2 , mit dem der erste LAS uber ein Inter LAS- 
Protokoll kommuniziert . 

Die zwei unabhangigen Anwendungsprotokolle wollen beide an 
alle Teilnehmer im selben Gebiet eine SMS senden. Dieses 
Gebiet wird von den zwei unabhangigen Netzen, reprasentiert 
von GMLC1 und GMLC2 , betreut . 

Nachrichten 1 und 2: 

GMLC1 und GMLC2 senden ihre Ortsinf ormationskoordinaten der 
Areas fur die sie zustandig sind und optional Struktur und 
Ort der Location Areas und Funkzellen zum LAS. Zusatzlich 
kann die Nachricht eine Struktur der Identitaten enthalten 
und/oder eine Liste von derzeit aktiven Identitaten in dieser 
Area . 

Nachricht 3 : 

Der LAS ist fur einen Teil des Ortes vom GMLC2 nicht zustan- 
dig, deshalb wird der entsprechende Teil der Inf ormationen in 
einer Nachricht zum LAS 2 wei tergelei tet . In dieser kleinen 
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v, nicht optimal zu sein, aber es 

Netzkonfiguration schemt das nicnt op 

zeigt die Flexibility des Protokolls. 

De^nal client 1 sendet einen AREA_REQUEST an den LAS, 
di eser entn,lt eine Beschreibung der angef orderten Area. 

"iVieser angef orderten Area (Subarea 0) wird nicht v 
Ein Ten ax nrtsserver LAS 2 behandelt. Deshalb 

LAS, sondern vom zweiten Ortsserver 

wird diese Anforderung an den LAS2 weitergeleitet . 

npl - pnd et. Diese enthalt die Suoarea ±, 
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benutzt werden 
Nachricht 7: 

Das Gleiche gilt fur GMLCl 



Nachricht 8: Standard MLP-Protokoll- 

Au ch der Ortsserver LAS2 sendet ^ ^ 

nachrichten fur die Area, die vo 
25 an den GMLC2 . ' ^ 

Nachricht 9: ne 0rtsnach _ 

Au ch der zweite external ■ client 2 sendet ^ 
fra ge ARE A_RE QUE S T fUr dieselbe Area -e ^ 
ortsserver LAS bemerkt diese Tatsacne, u * 
Ortsserve ..>,*. H * er auf die Antworten der ersten 

handlung dieser Nachricht, da er aur 

Anfrage wartet (Nachricht 4) . 



30 



Nachricht 10. ™, T( ~i narin ent- 

mnf , nnt . d ie Antworten vom GMLCl. Darin ent 
-3 c, Der ortsserver empfangt aie <v^«v 
35 Der ux t iste von Identitaten und lhrer 

hal f en sein kann erne lange Liste 

0r t S a„ g a b en odar F e h le« ld u» 9 e, Diese ^twort w lrd ^ 
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chert, bis alle angef orderten Inf ormationen eingetroffen 
sind, Oder bis eine Zeituberschreitung eintritt. 

Nachricht 11: 

Das Gleiche gilt fur den GLMC2 . 
Nachricht 12: 

Auch der zweite Ortsserver LAS 2 sammelt Inf ormationen . 
Nachricht 13 : 

Der. zweite Ortsserver LAS 2 erzeugt eine temporare Identitat 
RESP__ID_1 flir die gesammelten Teilnehmeridentitaten und einen 
Identif ikator AREA__ID_1 flir diese Area zur spateren Benut- 
zung. Diese werden an den Ortsserver LAS gesendet. 

Nachricht 14 : 

Der Ortsserver LAS hat nun alle notwendigen Inf ormationen, er 
erzeugt ebenfalls eine temporare Identitat RESP_ID_2 und ei- 
nen Identif ikator AREA_ID_2 fur diesen Bereich fur spatere 
Benutzung. Diese werden an den ersten external client 1 ge- 
sendet. 

Nachricht 15: 

Nun kann auch die Ort snachf rage ARE A_RE QUE S T vom external 
client 2 beantwortet werden. Es werden nur Inf ormationen 
benutzt, die durch die erste Anfrage vom external client 1 
gesammelt wurden. 

Nachricht 16: 

Der external client 1 will nun eine Kur znachricht SMS an alle 
Teilnehmer senden, die sich in der vorhin angegebenen Area 
befinden. Er sendet daher eine SUBMIT_INFO Nachricht mit dem 
Text der SMS an den Ortsserver LAS an die dort gespeicherte 
Liste mit der Identitat RESP ID 2. 



Nachricht 17: 



200303277 



26 



r, sr Observer LAS wird den Text dieser Kurznachricht SMS an 
Der Ortsservei GLMCl zuvor 

alle Teilneh^eridentitaten sende d» er normalerweise 
gespeichert hat. In diesem Fall ist cias 



;i7ht der GLMC/ sondern ein Netz.noten, der fttr Kurz- 
nachrichten verantwortlich ist. 

Nachricht 18: 

Das Gleiche gilt- fur den GMLC2 . 

Nachricht 19: ... SUBMIT INFO an den 

Die Information wird nun auch mttel SUB fc 

o T7\q? aesendet, wobei Rbbfuw^i^ 
Ortsserver 2 LAbZ geseuwi., 

wird- 

Nachricht 20: N _ rhricht 17 we iter oben 

Auch Ortsserver 2 LAS2 wira, 
beschrieben, vorgehen. 
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Patentanspruche 

1 . Verf ahren zur Behandlung eines ortsabhangigen Dienstes, 
fur einen abgegrenzten geographischen Bereich (Area) 
5 der bedient wird von mindestens. zwei Einrichtungen zur 

Bestimmung der geographischen Position von 
Mobilfunknutzern (GMLC) , 

fur eine Mehrzahl von Teilnehmern in diesem geographischen 
Bereich, 

10 bei dem von dem ortsabhangigen Dienst (LCS) eine Anfrage 

zur Identitat von Teilnehmern in diesem geographischen Be- 
reich (Area) von einem zentralen Net zelement (LAS1) 
P empf angen wird und 

das zentrale Netzelement dem ortsabhangigen Dienst eine 

15 aktuelle Information liber die in dem abgegrenzten geogra- 

phischen Bereich aktiven Teilnehmern von den mindestens 
zwei Einrichtungen zur Bestimmung der geographischen Posi- 
tion von Mobilfunknutzern (GMLC) abfragt, und 
das zentrale Netzelement das Ergebnis dem ortsabhangigen 

20 Dienst (LCS) zurucklief ert . 



2. Verf ahren nach Patentanspruch 1, 

dadurch gekennzeichnet, dass 

25 sich eine erste Einrichtung zur Bestimmung der geographi- 

^ schen Position von Mobilfunknutzern (GMLC Network 1) in- 

nerhalb der Inf rastruktur eines ersten Mobilf unknetzes und 
eine zweite Einrichtung zur Bestimmung der geographischen 
Position von Mobilfunknutzern (GMLC Network 2) innerhalb 

30 der Inf rastruktur eines zweiten Mobilf unknetzes befindet. 

3. Verf ahren nach einem der vorigen Patentanspruche, 

dadurch gekennzeichnet, dass 

das zentrale Netzelement nach Erhalt einer Anfrage zu- 
35 nachst iiberpruft, ob das gewiinschte Ergebnis bereits als 

Ergebnis einer friiheren Anfrage gespeichert hat und zu- 
rlickliefern kann oder 
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ob das zentrale Netzelement das gewunschte Ergebnis bei 
der mindestens einen Einrichtung zur Bestimmung der geo- 
graphischen Position von Mobil funknutzern (GMLC) abfragen 



muss . 



4. verfahren nach einem der vorigen Patent anspruche, 
dadurch gekennzeichnet , dass 

das zentrale Netzelement nach Erhalt einer Anfrage zu- 
nachst uberpruft, ob die gewunschte Anfrage bereits durch- 
gefuhrt wurde oder auf das Ergebnis der fruheren Anfrage 
noch gewartet wird, und 

nach Empfang des Ergebnisses der fruheren Anfrage auch dxe 
Anfrage beantwortet werden kann. 

S.Verfahren nach Patentanspruch 3, 
dadurch gekennzeichnet, dass 

ein durch das zentrale Netzelement bei einer Einrxchtung 
zur Bestimmung der geographischen Position von Mobxlfunk- 
nutzern abgefragte Ergebnis mit einer zus^tzlichen Kenn- 
zeichnung, insbesondere einem Zeitstempel und/oder einer 
Angabe zur Genauigkeit der Abfrage, versehen wxrd und dre 
Wieder-Verwendung des gespeicherten Ergebnisses fur exne 
mindestens zweite Anfrage abhangig von der zusatzlichen 
Kennzeichnung geschieht. 

6. Verfahren nach Patentanspruch 1, 
dadurch gekennzeichnet, dass 

das zentrale Netzelement die Ergebnisse der Abfragen von 
den mindestens zwei Einricntungen zur Bestimmung der geo- 
graphischen Position von Mobilf unknut zern (GMLC) sammelt 
und sobald alle abgefragten Einrichtungen zur Bestimmung 
der geographischen Position von Mobilf unknut zern geantwo 
tet haben, die Antworten zusammenf asst und das Ergebnrs 
. dem ortsabhangigen Dienst (LCS) zurucklief ert . 

7. Verfahren nach Patentanspruch 1, 
dadurch gekennzeichnet, dass 
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das Gebiet der Anfrage ein erstes geographisches Gebiet 
(Location Area 1) umfasst, fur das ein erstes zentrales 
Netzelement (LAS1) zustandig ist, 

und ein zweites geographisches Gebiet (Location Area 2) 
5 umfasst, fur das ein zweites zentrales Netzelement ( LAS 2 ) 

zustandig ist, und 

dass das erste zentrale Netzelement (LAS1) eine Anfrage 
erhalt, und diese Anfrage fur das zweite geographische 
Gebiet an das zweite zentrale Netzelement ( LAS 2 ) weiter 
10 gibt ( ARE A_RE QUE S T (subarea) ) . 

i v 8. Verfahren nach Patentanspruch 1, 
'4^ '» dadurch gekennzeichnet , dass 

das zentrale Netzelement (LAS) die Ergebnisse der Anfragen 
15 als Liste speichert und nur die Kennzeichnung der Liste 

dem ortsabhangigen Dienst (LCS) zuriicklief ert . 

9. Verfahren nach Patentanspruch 8, 

dadurch gekennzeichnet, dass 
20 das zentrale Netzelement (LAS) zusatzlich Eigenschaf ten 

der ermittelten Teilnehmer von den Einrichtungen zur 
Bestimmung der geographischen Position von 
Mobilf unknutzern (GMLC) ubermittelt bekommt oder 
anderweitig ermittelt, diese sammelt und zur spateren 
f n~JL 5 Verwendung speichert, und zusammen mit der Kennzeichnung 

v der Liste dem ortsabhangigen Dienst (LCS) zuriicklief ert . 

10. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet, dass 

30 das zentrale Netzelement (LAS) eine Zuordnung zwischen 

der Identitat mindestens eines Teilnehmers, fur den eine 
Ortsinf ormation abgefragt wird, und den fur diesen 
Teilnehmer verantwort lichen Netzknoten beinhaltet und 
wenn das zentrale Netzelement eine Anf ragenachricht vom 

35 ortsabhangigen Dienst (LCS) erhalt verteilt er diese 

Anfrage an j ede Identitat, die fur diesen Netzknoten 
gespeichert ist. 
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11. vorrichtung zum Behandeln von Anfragen eines ortsabhangi- 
gen Dienstes, 

fur einen abgegrenzten geographischen Bereich (Area) 
der bedient wird von mindestens zwei Einrichtungen zur 
Bestimmung der geographischen Position von 
Mobilfunknutzern (GMLC) , 

fur eine Mehrzahl von Teilnehmern in diesem geographischen 

Bereich, , 
mit Mitteln zum Empfang von vom ortsabhangigen Dienst 
(LCS) gesendeten Anfragen zur Identitat von Teilnehmern m 
diesem geographischen Bereich und ^ 
rait Mitteln zum Senden einer Abfrage von aktuellen Infer- . 
mationen uber die in dem abgegrenzten geographischen Be- 
reich aktiven Teilnehmern an eine Einrichtung zur Bestim- 
mung der geographischen Position von Mobilfunknutzern 
(GMLC) > und 

. mit Mitteln zum Empfangen der Antworten von der angefrag- 
ten Einrichtung zur Bestimmung der geographischen Position 
von Mobilfunknutzern (GMLC) , und 
mit Mitteln zur Bearbeitung der Antworten, und 
mit Mitteln zum Senden des Ergebnisses an den ortsabhangx- 
gen Dienst (LCS) . 

12 Vorrichtung nach Patent anspruch 11 ^ 
mit Mitteln zum Speichern (DB) der Antworten von der 
angefragten Einrichtung zur Bestimmung der geographischen 
Position von Mobilfunknutzern und einer zusatzlichen 
Kennzeichnung der Antworten, und 

mit Mitteln zum Vergleichen einer neuen Anfrage mit den 
bereits gespeicherten Antworten. 

13 vorrichtung nach Patentanspruch 11 

mit Mitteln zum Speichern (DB) der Antworten von der 
angefragten Einrichtung zur Bestimmung der geographischen 
Position von Mobilfunknutzern und Senden einer eindeutigen 
Kennzeichnung der Antworten, und 
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mit Mitteln zum Benutzen der eindeutigen Kennzeichnung der 
Antworten in darauf f olgenden Nachrichten vom orts- 
abhangigen Dienst (LCS) 
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Zusammenf as sung 

Verfahren und Vorrichtung zur Behandlung von ortabaaierten 
Diensten 

Die Erfindung betrifft ein Verfahren zur Behandlung einea 
ortaabhangigen Dienstea, fur einen abgegrenzten ^ographx- 
schen Bereich (Area) der bedient wird von mindestena zwez 
Eznrichtungen zur Bestimmung der geographiachen Posrtzon von 
Eznncntung Mehrzahl von Teilnehmern in 

Mobilfunknutzern (GMLC) , tur erne 

diesem geographiachen Bereich. 

° y . „. nr e< sendet eine Anfrage zur Iden- , 

Der ortaabhangige Dienst (LCS) senaer e ,»-.„f 
titat von Teilnehmern in diesem geographiachen Bererch (Area, 
an ein zentrales Netzelement (LAS1) worauf das zentrale 
^element anstatt des ortaabhangigen Dienstea die aktuelle 
information uber die in dem abgegrenzten geographrachen 
Bereich aktiven Teilnehmern von den mindestens zwei 
Sinrichtungen zur Bestimmung der geographiachen Posrtzon von 
Mobilfunknutzern ( GMLC ) abf ragt . Daa zentrale Netzelemen 
, liefert dann das Ergebnia dem ortaabhangigen Drenat (LCS) 

Dif Erfindung betrifft weiterhin eine Vorrichtung zur Durch- 
fuhrung des Verfahrens. 

5 Figur 2 
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Fig. 3 
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Fig. 5 
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Fig. 6 
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